1. Field of the Invention
The invention relates to a cellular terminal, method and a system for fetching content from a server to a cellular terminal.
2. Description of the Prior Art
The Wireless Application Protocol (WAP) is a result of continuous work to define an industry wide standard for developing applications over cellular communication networks. This makes it possible to access for example the Internet or other kinds of information networks provided with hypermedia servers, from an ordinary cellular phone supporting WAP. These types of cellular phones which support WAP, have only a small fraction of the resources of a typical desktop or portable computer. This means that the features in the phone are very limited compared to a computer. The reason for this limitation is the size of the phones, i.e. the phone has a severe limitation in processing power, memory space, display size and buttons or keys by which a user can request, view and manipulate information obtained from a hypermedia server. Therefore, it is very important that the features in the phone are made as efficient as possible. Also, the relatively high cost for a call from a cellular phone makes it also very important to provide the client with a fast response from the server.
The WAP Architecture is very similar to the Internet Architecture. FIG. 1 shows a comparison between the Internet Architecture 10 and the WAP Architecture 20. The Internet Architecture 10 comprises a Hypertext Markup Language (HTML) 12, e.g. Java Script, a Hypertext Transfer Protocol (HTTP) 14, Transport Layered Security (TLS) I Secure Sockets Layer (SSL) 16, and a Transport Configuration Protocol (TCP) I User Datagram Protocol (UDP) 18.
The Internet Architecture 10 is well known prior art, and is disclosed in e.g. in U.S. Pat. No. 5,657,390. The WAP Architecture 20 comprises a Wireless Application Protocol (WAE) 22 corresponding to HTML 12, a Wireless Session Layer (WSP) 24 corresponding to HTTP 14, a Wireless Transport Layered Security (WTLS) 26 corresponding to TLS/SSL 16, and a Wireless Transport Layer (WTP) 28 corresponding to TCP I UDP 18. Furthermore, the WAP Architecture comprises different bearers 29 like e.g. SMS, USSD and CDMA 30. There is also a possibility to implement different kinds of services and applications in the WAP Architecture, e.g. Value Added Services (VAS). The WAP Architecture 20 is well known prior art and is therefore not being disclosed any further. More detailed information about WAP can at present be found at the following Internet address: http://www.wapforum.org/
A Wireless Application Environment which forms a upper layer of the WAP stack includes a browser application, even called a microbrowser. The browser uses wireless mark-up language (WML) and a lightweight mark-up language, WMLScript a lightweight scripting language. WML implements a card and deck metaphor. The interaction of the browser and user is described in a set of cards which are grouped together into a document commonly referred to as a deck. The user navigates to a card in a deck reviews its content and then navigates to another card in the same deck or in a different deck. Decks of cards are transferred from origin servers as needed.
U.S. Pat. No. 5,895,471 discloses a way of storing hypermedia links, used by a cellular phone. The hypermedia links are stored as bookmarks on a server to save memory space in the phone. The hypermedia links could be identified as uniform resource locators (URL), which are used to identify and control access to resources on a network like the Internet. U.S. Pat. No. 5,895,471 also gives a basic indication of how WAP is working, e.g. it describes how the hypermedia information is organized into cards and decks. Instead of referring to WML, they refer to a language mentioned as Handheld Device Markup Language (HDML). Furthermore, it is mentioned that the phone can be provided with a cache memory, to store received decks from a hypermedia link. Thus, it is possible that the phone first consults the cache to determine if a requested deck is available in the phone. If the deck is available, it can be accessed without requiring any communication with the network. It is also mentioned how to store navigation history of hyperlink traversals and a history of user activity.
However, in some cases, history and bookmark information is not always well suited for navigation. While some of the content in the decks or cards may include internal hypermedia links that point to different locations within the same deck/card, history and bookmark information permits navigation within such decks/cards only to particular locations specified by the internal hypermedia links, instead, separate mechanisms such as scroll bars must be used as the principal mechanisms for navigating to particular locations within decks/cards. Consequently, an end user is often forced to consciously click on different objects in a graphical user interface depending on different objects in a graphical user interface depending upon whether the end user wishes to navigate between decks/cards or to navigate within decks/cards. As a result, navigation with this type of user interface is slow and burdensome for many end users.
As mentioned in U.S. Pat. No. 5,895,471, it is possible to access content from an earlier session, even when the phone is out of coverage, if the content has been stored in the cache. However, even if the user has downloaded to the cellular phone with a hierarchy of cards/decks from hypermedia links, the user cannot always rely on that all the links have been stored in e.g. a cache memory. One reason, for the deck/card not being stored in the cache, could be that the user did not access this deck/card. Another reason could be that one of the cards/decks was deleted during a visit to other links, e.g. older cards/decks saved in the cache are dropped to allow new cards/decks to be stored instead. Typically, the cards/decks which are deleted/inserted according to a First In First Out (FIFO) principle. Furthermore, the user cannot be sure if all the content stored in the cache connected to the same cards/decks is updated. For example, if the content on the server has changed, and includes new links which will not be apparent in an update with the server. Accordingly, the user will not be able to receive this information, since the update is mostly related to the existing decks/cards in the cache.
Therefore, a significant need exists for a manner of ensuring that the phone has received the latest content together with associated links, which could be relevant for the user. Moreover, there is a need for the user to facilitate a download of decks/card, especially to access content at a later occasion e.g. when the user is in an out of coverage area, or so called off-line.